Report  Documentation  Page 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 

1.  REPORT  DATE 

2QQ^  2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-2006  to  00-00-2006 

4.  TITLE  AND  SUBTITLE 

Architecture-Based  Systems  Engineering 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Department  of  Defense, Test  Resource  Management  Center, 1225  S.  Clark 
St.,  Ste.  1200, Arlington, VA, 22202 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF:  17.  LIMITATION  OF 

_ _ _  ABSTRACT 

18.  NUMBER  19a.  NAME  OF 

OF  PAGES  RESPONSIBLE  PERSON 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE  Same  aS 

unclassified  unclassified  unclassified  Report  (SAR) 

2 

Standard  Form  298  (Rev.  8-98} 

Prescribed  by  ANSI  Std  Z39-18 


TECHNOTES 


Architecture-Based  Systems  Engineering 


G.  Derrick  Hinton 

Central  Test  and  Evaluation  Investment  Program  (CTEIP), 
Test  Resource  Management  Center  (TRMC),  Arlington,  Virginia 


Test  and  evaluation  (T&E)  assets — instmmen- 
tation,  hardware-in-the-loop  facilities,  pro¬ 
cessing  software,  simulations  and  more — have 
been  developed  over  the  years  to  meet  a  wide 
variety  of  needs  and  requirements.  Generally,  each  of 
these  assets  has  been  developed  by  using  standard  sys¬ 
tems  engineering  processes,  in  which  requirements  are 
analyzed,  a  design  is  created,  hardware  and  software  are 
manufactured  and  integrated,  and  the  resulting  asset  is 
tested.  Such  a  process  results  in  superb,  but  limited, 
point  solutions  to  recognized  problems  and  does  not 
usually  result  in  a  solution  that  might  have  applicabili¬ 
ty  to  more  global  TScE  needs.  The  achievement  of 
these  higher-level  goals  requires  a  modification  to  the 
standard  systems  engineering  process  by  creating  an 
architecture  as  the  central  aspect  of  the  requirements  and 
design  process. 

An  architecture  is  a  segmentation  of  a  system  (or  sys- 
tem-of-systems)  such  that  the  primary  pieces  are  iden¬ 
tified  and  their  purpose,  function,  interfaces,  inter¬ 
relatedness  and  guidelines  for  their  evolution  over  time 
are  defined.  Architectures  put  constraints  on  designers 
and  developers.  These  constraints  make  possible  the 
achievement  of  higher-level  goals  that  would  not  auto¬ 
matically  be  achieved  if  developers  worked  independ¬ 
ently.  These  higher-level  goals  are  called  the  system’s 
driving  requirements.  A  system  may  have  hundreds  or 
thousands  of  individual  requirements;  however,  the 
driving  requirements  are  those  overarching  requirements 
upon  which  the  purpose  of  the  system  depends.  Once 
these  requirements  are  identified,  it  is  a  relatively 
straightforward  process  to  segment  the  system  and 
address  these  requirements.  The  architecture  is  then 
used  as  a  starting  point  for  a  design  to  fulfill  all  of  the 
numerous  detailed  requirements. 

An  architecture  is  thus  a  bridge  from  requirements  to 
design,  in  which  the  most  important,  critical  or  abstract 
requirements  are  used  to  determine  a  basic  segmenta¬ 
tion  of  the  system.  An  architecture  has  costs  (the  con¬ 
straints)  and  benefits  (the  achievement  of  the  driving 
requirements  and  the  facilitating  of  the  system  design). 


A  good  architecture  is  one  that  achieves  the  driving 
requirements  using  the  minimum  number  of  con¬ 
straints  (that  is,  at  minimum  cost).  It  is  important  to 
note  that  all  systems  have  architectures,  even  if  they  are 
unstated.  The  issue  is  whether  an  explicit  architecture 
is  defined  for  a  system  to  ensure  that  its  driving 
requirements  are  met. 

In  addition  to  ensuring  that  a  system  can  meet  broad 
goals,  an  architecture  also  focuses  attention  on  those 
areas  of  technological  immaturity  that  prevent  the  full 
achievement  of  the  driving  requirements.  Thus,  the 
architecture  can  vividly  identify  the  “long  poles  in  the 
tent”  that  require  science  and  technology  investment. 
Current  efforts  to  develop  non-intrusive  instrumenta¬ 
tion  have  relied  on  architecture  development  as  the  core 
tool  for  identifying  technology  shortfalls.  This  has  led 
to  research  into  advanced  “smart”  sensors  that  will  be 
self-calibrating  and  will  not  rely  on  the  test  article  for 
power  or  communications.  Such  non-intrusive  sensors 
will  allow  testing  of  advanced  weapon  systems  without 
the  need  to  heavily  modify  the  test  article  to  install 
instrumentation  systems.  Without  an  overall  architec¬ 
ture,  each  new  technology  development  would  focus  on 
a  single  “point  solution”  with  little  relationship  to  other 
assets  or  the  broad  Department  of  Defense  (DoD)  and 
range  community  goals  and  strategies.  With  an  archi¬ 
tecture,  each  new  system  can  address  a  piece  of  the 
whole  puzzle  rather  than  simply  addressing  individual 
issues  out  of  context. 

While  architecture-based  development  has  gradually 
taken  a  more  prominent  role  in  DoD  design  practice, 
there  is  little  agreement  in  the  general  engineering  com¬ 
munity  over  the  actual  definition  of  an  architecture.  The 
Institute  of  Electrical  and  Electronics  Engineers  gives 
general  guidelines  on  what  an  architecture  is,  and  in  the 
software  engineering  field,  the  principals  of  Rational 
Software  Corporation  (now  owned  by  IBM)  have  done 
a  significant  amount  of  work  defining  a  “Rational 
Unified  Process  for  Systems  Engineering”  in  which  to 
discuss  software  architectures.  The  Reference  Model  for 
Open  Distributed  Processing  (RM-ODP)  is  another 
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attempt  at  describing  architectures  in  a  systematic  way. 
However,  industry  acceptance  has  been  slow  in  coming. 

In  an  effort  to  promote  interoperability  and  cost- 
effective  development  of  software  systems,  the  Defense 
Science  Board  in  the  early  1990s  suggested  that  DoD 
establish  architectural  guidance  for  all  DoD  military 
systems.  This  initiative  has  culminated  in  the  creation 
of  the  DoD  Architecture  Framework  (DoDAF),  a 
guide  for  system  architects  to  document  an  architecture 
in  a  standard  way  so  that  architectures  can  be  compared 
and  contrasted.  The  DoDAF  lists  a  number  of  views, 
each  one  focusing  on  a  particular  aspect  of  the  architec¬ 
ture  (see  Figure  1 ). 


first  step  in  TScE  architecture-based  development  was  the 
creation  and  widespread  deployment  of  the  Test  and 
Training  Enabling  Architecture  (TENA),  which  was 
designed  to  enable  interoperability  and  reuse  among  range 
software  systems.  Additional  architecture-based  develop¬ 
ment  is  ongoing  under  the  auspices  of  OSD,  such  as  the 
Integrated  Network-Enhanced  Telemetry  (iNET)  project, 
the  Data  Management  project,  the  T&E  for  Directed 
Energy  project  and  others.  The  end  goal  of  OSD’s  com¬ 
mitment  to  architecture-based  development  is  the  creation 
of  new  TScE  assets  that  not  only  fulfill  their  narrow  pur¬ 
poses  but  also  fit  into  an  interoperable,  DoD-wide  com¬ 
mon  range  infrastructure  for  the  next  30  years.  □ 
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Figure  1.  DoD  Architecture  Framework  (DoDAF) 


The  Office  of  the  Secretary  of  Defense  (OSD)  has 
taken  the  lead  for  creating  an  overall  architecture  for  TScE 
assets.  Each  new  TScE  project  is  being  asked  not  only  to 
create  an  architecture  for  that  specific  project’s  deliverables, 
but  also  to  address  how  those  deliverables  would  fit  into  an 
overall  TScE  integrated  architecture.  Among  the  integrat¬ 
ed  architecture’s  driving  requirements  are  interoperability 
among  assets,  reusability  across  ranges  and  services,  spec¬ 
trum  efficiency  and  enablement  of  net-centric  testing.  The 
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